With the widespread international use of software, producers of software have had a need to translate information displayed to a user to the natural languages of countries and localities where that software is to be marketed or sold. The method depicted in FIG. 1 represents one common method, useful to illustrate the issues associated with that translation as it relates to software development.
The software to be developed is authored in source code 10, which is rendered in a programming language. Source code 10 may be manipulated to produce an application 12, which is installable and executable on a destination computer, for example a user computer. Presently, the production of an application 12 may be rendered in any number of ways through a processor 11, which might compile and/or package the objects of the application 12 for use. If application 12 is compiled, then processor 11 will include a compilation step. Likewise, if application 12 is interpreted, source code may not need to be rendered into a non-original format, and may simply be packaged into an installation object. The principles disclosed herein relating to translation apply generally regardless of the type of application production process used.
Source code 10 traditionally has embedded therein certain messages for the end user, for example in the form of “print” statements. In its usual format, source code is generally not suitable for translation. Most persons who perform translation services are not skilled in programming, and therefore may err in translating text that is not destined for the end user (statements in a programming language) and may also miss user messages embedded deep within the source code.
For this, and perhaps other reasons, a practice has developed of placing the user-viewable messages, which are in the example of FIG. 1 merely textual strings, into “resource files”. A resource file 13 contains user-visual content of the application, separated from and referenced by the source code 10. As source code 10 is compiled, packaged or otherwise processed, the resource file is included through source code references. A resource file 13 is generally simplified in format to make it easy for a translating person 14 to identify the content needing translation. Ideally, the translator 14 may edit the resource file 13, replacing the messages in the developer's language with messages in the language of the end user. Such an edited file 15 may be referenced by the source code 10, which in the course of application production produces a localized application 16 with translated messages in the language of an end-user.
This method of resource file usage has certain disadvantages. More apparently, the creation of a resource file may be laborious and expensive, requiring potentially some work on the part of a software developer to identify and isolate the natural language content needing to be translated. However, some modern application development suites can automatically create and maintain resource files, particularly those for writing graphical user interface applications, so this disadvantage is by no means universal.
This method also interferes with the software development process. Software development is largely concerned with the functionality of an application, for example the interaction between the application and other applications, devices and data. Generally speaking, the internals or “guts” of an application are first built and tested, followed by refinement of the “look and feel.” The normal course of development uses only the user-visual information in the language of the developers until nearly the end of the development cycle, shortly before product release.
Because in most of the early development the user interfaces are incomplete or in flux, resource files are typically sent out for translation late in the development cycle when the application and the user interface becomes reasonably stable. Unfortunately, some translations are difficult to get performed rapidly, which can result in a delay in the release of an application of several weeks to months. The alternative is to release an application early in the developer's language, followed by a subsequent international release. However, it may be that the application at that time will include bug fixes not in the initial release, which can lead to problems with application support. Additionally, the user interface must be frozen during this time of translation, as the addition or change of functionality might require additional translations, which can prevent additional features or functionality from appearing in a localized software product.
Furthermore, in that method frequent updates to the resource files are cumbersome. Although it is possible for a resource file to be submitted early to a translator, doing so can lead to unnecessary translations and expense. Translation services are typically operated “in bulk”, meaning that a service will accept for translation a large quantity of material in print or electronic document format. These services typically charge by the line, word or string, so if there is a duplicated string in the source code, as there often will be, a translator is likely to slavishly translate the material in a once-through procedure, and merrily charge additional fees for the duplicated material. Additionally, these services are generally not equipped to compare a previously submitted document with another, and provide only translations for the updated material. Thus it is left to the developer to manually extract updated strings and eliminate any duplicates, or otherwise incur additional costs for the translation of redundant material.